1. Field of the Invention
The present invention generally relates to computers and software, and more particularly, to the security involved in remote command execution. Remote command execution is a process where a local host processor causes a program to be executed on a remote host processor. Usually, the calling process passes data to the remote program and captures the output generated by the remote program on the remote host.
2. Description of Related Art
As known in the computer and software arts, a remote procedure call (RPC) is equivalent to a call to a local subroutine. An application program that makes the call executes the call statement, passes the parameters to the called procedure, and then waits for the results to be passed back from the called procedure. However, unlike a local procedure call, the procedure called by the RPC does not reside in the application program or may not even reside in the computer running the application program, but instead resides on a remote computer in a network. It is also known that an RPC can be used for remote command execution.
In unix computing, the existing art for executing commands remotely consists of the Berkely Software Distribution Unix (BSD) 4.3 family of commands and procedure calls (rsh (remsh), rcmd, rexec) and the RPC-based on/rexd combination developed by Sun Microsystems, Inc.
The BSD facilities rely on a programming interface known as "sockets," wherein a two-way connection is created between the client and the server. "On" and "Rexd" are based on remote procedure calls, which is a programming interface wherein procedure calls are made transparently on the client, but execute on the server.
In all cases, a "daemon" program running permanently on the server system has the responsibility of creating or denying the connection from the client application to the service provider; or server application.
A key difficulty with remote command execution is that of security. How does one ensure that only allowed users from allowed client systems are permitted access to the server application, and also ensure that access cannot be perverted to malicious purposes?
The method used in BSD 4.3 unix works as follows. (1) The server checks the client's TCP port (an address associated with a socket, to ensure that it is a reserved port. (2) The server reads the following inputs from the client: the client-side user name, the requested server-side user name, and the command to be executed. (3) The requested user name on the server is looked up in the password database on the server system. If there is no entry, then the connection is terminated. (4) One of two authorization files (/etc/hosts.equiv, and the.rhosts in the user's home directory) are checked for the client host name and the client user name.
If all these checks pass, execution of the command is allowed.
The RPC-based remote execution facility produced by Sun Microsystems, Inc. has inherently almost no security--if the same user ID exists on the server as on the client, execution is allowed. The one significant restriction is that no remote execution is allowed by root. There is a command line option to rexd that causes it to rely on the BSD 4.3 security mechanism described above.
The prior solutions for remote command execution suffer from the following security weaknesses. It will be shown later how the present invention addresses and overcomes certain of these difficulties. A problem with the prior solutions is that the host addresses and user names are sent in plain text that is very open to "spoofing". A knowledgeable hacker can transmit packets pretending to be from another machine or another user.
Another problem is that the authentication is weak, because the server accepts the user and host name as identified in the transmission without proof.
Yet another problem arises in cases where passwords are required. They are transmitted over the network in clear text, which is subject to interception.
Another problem is that the authorization files not very well protected. The files .rhosts and /etc/hosts.equiv are used to circumvent sending passwords, but they are not well protected. The /etc/hosts.equiv file is generally write-protected to root only, but individual users' .rhosts are often not well-protected, and it is hard to enforce strong protection. They can be modified to allow unintended users to execute commands.
Furthermore, there is the problem that no state is maintained since each command transaction stands alone. This leaves these methods open to "replay attacks" wherein a hacker captures a valid network packet, alters some details (like the name of the user, or the command to execute) and resends it.
In addition, there is the problem that there are few options for additional security. The file /var/adm/inetd.sec can be used to limit accessibility of the services to a specific set of hosts. There are no options to encrypt data or obtain stronger authentication. There are additional levels of security that can be imposed on unix systems at the operating system level. These are special versions of unix, usually developed independently by vendors to meet the government B2 Security requirement. These are outside the scope of the present invention, as they require a special version of unix.
Another method of imposing stronger security on unix operations without modifying the base operating system is the Kerberos system. Kerberos uses a "third party," a separate computer designated as the security server. All "principals" in the distributed network must be known to the security server, and all have passwords, or keys, known only to themselves and the security server.
Each principal (which may be a user or a program) must obtain a set of credentials, known as a ticket, from the security server before it may perform any functions over the network. In addition, before a client can connect to a server, it must obtain a different, specific ticket from the security server which it presents to the server. All keys and tickets are encrypted in such a way that only the intended recipient can decrypt them.
However, until now, network systems have lacked the ability to provide flexible and heightened security for remote procedure calls in the distributed computing environment (DCE).